Product Code Database
An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.
A web app which provides message management, composition, and reception functions may act as a Web email, and a piece of computer hardware or software whose primary or most visible role is to work as an email client may also use the term.
Emails are stored in the user's mailbox on the remote server until the user's email client requests them to be downloaded to the user's computer, or can otherwise access the user's mailbox on the possibly remote server. The email client can be set up to connect to multiple mailboxes at the same time and to request the download of emails either automatically, such as at pre-set intervals, or the request can be manually initiated by the user.
A user's mailbox can be accessed in two dedicated ways. The Post Office Protocol (POP) allows the user to download messages one at a time and only deletes them from the server after they have been successfully saved on local storage. It is possible to leave messages on the server to permit another client to access them. However, there is no provision for flagging a specific message as seen, answered, or forwarded, thus POP is not convenient for users who access the same mail from different machines.
Alternatively, the Internet Message Access Protocol (IMAP) allows users to keep messages on the server, flagging them as appropriate. IMAP provides folders and sub-folders, which can be shared among different users with possibly different access rights. Typically, the Sent, Drafts, and Trash folders are created by default. IMAP features an IMAP IDLE for real-time updates, providing faster notification than polling, where long-lasting connections are feasible. See also the remote messages section below.
The JSON Meta Application Protocol (JMAP) is implemented using JSON APIs over HTTP and has been developed as an alternative to IMAP/SMTP.
In addition, the mailbox storage can be accessed directly by programs running on the server or via shared disks. Direct access can be more efficient but is less portable as it depends on the mailbox format; it is used by some email clients, including some webmail applications.
The email clients will perform formatting according to for headers and body, and MIME for non-textual content and attachments. Headers include the destination fields, To, Cc (short for Carbon copy), and Bcc ( Blind carbon copy), and the originator fields From which is the message's author(s), Sender in case there are more authors, and Reply-To in case responses should be addressed to a different mailbox. To better assist the user with destination fields, many clients maintain one or more address books and/or are able to connect to an LDAP directory server. For originator fields, clients may support different identities.
Client settings require the user's real name and email address for each user's identity, and possibly a list of LDAP servers.
Client settings require the name or IP address of the preferred outgoing mail server, the port number, and the user name and password for authentication, if any. The following ports are used for email submission:
- Port 465 – The officially designated port for mail submission using TLS from the start of the connection (Implicit TLS), as per RFC 8314. Since encryption is enforced from the beginning, it eliminates the risk of downgrade attacks or MITM (Man-in-the-Middle) attacks that could strip away encryption.
- Port 587 – Commonly used for mail submission with support for STARTTLS, allowing the connection to be optionally upgraded to TLS. However, if a MITM attacker interferes with the STARTTLS command, the connection may remain unencrypted, making it less secure than implicit TLS on port 465.
Port 25, originally intended for message relay between MTAs, is not for client message submission and is often blocked by ISPs to prevent spam.
All relevant email protocols have an option to encrypt the whole session, to prevent a user's name and password from being Packet sniffer. They are strongly suggested for nomadic users and whenever the Internet access provider is not trusted. When sending mail, users can only control encryption at the first hop from a client to its configured outgoing mail server. At any further hop, messages may be transmitted with or without encryption, depending solely on the general configuration of the transmitting server and the capabilities of the receiving one.
Encrypted mail sessions deliver messages in their original format, i.e. plain text or encrypted body, on a user's local mailbox and on the destination server's. The latter server is operated by an email hosting service provider, possibly a different entity than the Internet access provider currently at hand.
Encrypting an email retrieval session with, e.g., SSL, can protect both parts (authentication, and message transfer) of the session.
Alternatively, if the user has Secure Shell access to their mail server, they can use SSH port forwarding to create an encrypted tunnel over which to retrieve their emails.
In both cases, only the message body is encrypted. Header fields, including originator, recipients, and often subject, remain in plain text.
Some websites are dedicated to providing email services, and many Internet service providers provide webmail services as part of their Internet service package. The main limitations of webmail are that user interactions are subject to the website's operating system and the general inability to download email messages and compose or work on the messages offline, although there are software packages that can integrate parts of the webmail functionality into the OS (e.g. creating messages directly from third party applications via MAPI).
Like IMAP and MAPI, webmail provides for email messages to remain on the mail server. See next section.
Another important standard supported by most email clients is MIME, which is used to send binary file . Attachments are files that are not part of the email proper but are sent with the email.
Most email clients use a User-Agent header field to identify the software used to send the message. This header field is defined for Netnews, but not-for e-mail, and, as such, is non-standard in e-mail headers.
, Message Submission for Mail, details the role of the Mail submission agent.
, Email Submission Operations: Access and Accountability Requirements, provides a survey of the concepts of MTA, MSA, MDA, and MUA. It mentions that " Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587" and that " MUAs SHOULD use the SUBMISSION port for message submission."
, An Extensible Format for Email Feedback Reports, provides "an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties."
| POP3 | incoming mail | 110 _pop3._tcp | 995 _pop3s._tcp | |
| IMAP4 | incoming mail | 143 _imap._tcp | 993 _imaps._tcp | |
| SMTP | outgoing mail | 25 | 587 | |
| MSA | outgoing mail | 587 _submission._tcp | 465 _submissions._tcp | |
| HTTP | webmail | 80 | 443 |
While webmail obeys the earlier HTTP disposition of having separate ports for encrypt and plain text sessions, mail protocols use the STARTTLS technique, thereby allowing encryption to start on an already established TCP connection. While used to discourage the use of the previously established ports 995 and 993, promotes the use of implicit TLS when available.
|
|
